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ABSTRACT 

The AIT/AIV of the Ariane4 Vehicle 
Equipment Bay has been held at Matra 
Marconi Space (MMS) site of Toulouse 
for several years. For this 
act ivity , inc ident interpret at ion 
necessitates a great deal of 
different knowledge. When complex 
faults occur, particularly those 
appearing during overall control 
tests, experts of various domains 
( EGSE , software, on-board equipment) 
have to join for investigation 
sessions. Thus, an assistance tool 
for the identification of faulty 
equipment will improve the efficiency 
of diagnosis and the overall 
productivity of test activities. 

As a solution, the Aramiihs (1) 
laboratory proposed considering the 
opportunity of a knowledge based 
system intended to assist the tester 
in diagnosis. This knowledge based 
system is, in fact, a short-term 
achievement of a long-term goal which 
is the capitalization of corporate 
memory in the Ariane4 test domain. 
Aramiihs is a research unit where 
engineers from MMS and researchers 
from the IRIT (2) -CNRS (3> cooperate on 
problems concerning new types of ma- 
system interaction. 
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I . INTRODUCTION 

Information technology can help 
companies achieve higher productivity 
and better reliability in decision 
making, communication and activities 


organization. With the large range 
of technical possibilities at hand in 
realizing applications, people become 
more and more aware of the importance 
of matching the right technique with 
the right need and of evaluating the 
impact of this solution upon 
organizations . 

So far, we are taking part in the 
emerging awareness of two fundamental 
aspects when new information 
processing systems are to be defined. 
These features have been recently 
taken into account in information 
technology and data processing system 
design and development. 

The first aspect stresses the 
evaluation of the aim impact (need 
analysis and organization study) and 
the choice of f an appropriate 
combination of techniques to achieve 
this aim. The second point focuses 
on the time required for the aim to 
be achieved. If realizing the 
application is to take a long time, a 
way to turn such a long-term project 
(which can make end users discouraged 
and unmotivated) into efficient 
short-term ones is to propose an 
incremental design and development. 
The objective then becomes the 
gradual realization of an application 


C1) Action de Recherche et 

Application Matra Irit en Interaction 
Homme Systeme 

(2) Insititut de Recherche en 
Informatique de Toulouse 

(3) Centre National de la Recherche 
Scientif ique 


441 



that gives benefits to its end users 
at each step of its achievement and 
thus will maintain the interest and 
participation of those end users. 

In this paper, we describe the 
development of a knowledge based 
system for diagnosis assistance. It 
is intended to be used in the context 
of Ariane4 Vehicle Equipment Bay 
( VEB) Assembly, Integration, Test and 
Validation (AIT/AIV) activities . 
This knowledge based system is, in 
fact, the first short-term 
achievement. The long-term goal is 
to capitalize technical memory in the 
Ariane4 test domain. 

The long-term aim is to make 
knowledge well provided among people 
in a work environment and to have 
them participate in the enrichment 
and standardization of it. Thus, we 
have to plan the gradual development 
of the final system. The amount of 
the capitalized knowledge will be 
more important than the one needed by 
a 'standard' expert system. It is 
possible that the final system will 
consist of several systems (expert 
systems, intelligent data bases with 
multimedia accesses, intelligent 
tutoring systems, etc.). The final 
impact is of great importance since 
it both modifies the way people work 
{ improves the productivity and skill 
of the staff) and the view they have 
of their work. 

We will also detail in the paper our 
approach which is a cross- 
disciplinary one since it includes 
software techniques. Artificial 
Intelligence, and human factors 
evaluation. Such an approach is 
possible, thanks to the context 
provided by the ARAMIIHS laboratory, 
where engineers and researchers 
cooperate on problems raised by the 
development of complex man/machine 
interfaces. 

OPERATIONAL NEEDS AND CONTEXT 
2,1 The Ariane4 VEB 

The AIT/AIV activities of the Ariane4 
launcher VEB have been performed at 
the Matra Marconi Space (MMS) site of 
Toulouse for more than 10 years, and 
will continue for 10 more years 
before being totally replaced by the 
Ariane5 launcher. 


The Ariane4 VEB is mechanically 
interdependent with the third stage 
of the launcher during the flight. 
It ensures the interface between the 
structure of the launcher and the 
satellite contained in the fuse cap. 

The functionalities of the VEB allow 
it tos 

- guide and control the launcher 
during the flight, 

- send orders to the three stages of 
the launcher for the trigger or stop 
of the propellant systems, the 
separation of the stages, the release 
of the fuse cap and the satellite, 
and the change of data format of the 
telemetry, 

- verify the state of the satellite 
and control its release, 

- satisfy security constraints by 
localizing the launcher and, if 
necessary, by destroying it, 

- allow, during the preparation of 
the launcher and its flight, the 
transmission of telemetries to 
control centers for the verification 
of the correct operation before 
launch and during flight, 

- and process, before launch, the 
telecommands necessary to control and 
bring into operation different 
elements of the launcher. In figure 
1, we have the different 
functionalities of the VEB. 
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2*2 The AIT/AIV Activities 

As it was said previously, the MMS 
site of Toulouse is in charge of the 
AIT/AIV activities of the VEB , Those 
activities include the last tests on 
the VEB before it is sent to Kourou 
(the launch site). 

2*2.1 Tester Behavior Confronted 
With an Incident 

During the test phase, when an 
incident occurs, integration 
responsibles begin the diagnosis by 
an analysis phase. This analysis 
phase requires understanding the 
context of anomalies through the 
appearance of symptoms, and having 
the appropriate knowledge, experience 
and information related to the 
incident. From this analysis phase, 
a hypothesis will be made. Then, 
there will be decisions on 
complementary tests to run in order 
to validate the hypothesis and to 
localize better the cause of the 
incident. 

Thus, those activities necessitate 
from testers a good amount of 
knowledge in test environment which 
is composed of: 

- the VEB under test 

- the test bench 

- the software of the on-board and 
ground computers 

- the specification of tests 

The knowledge lies both in documents 
and in the expert testers' 
experience. The documents needed 
during a diagnosis are numerous: 
ground software specifications, test 
specifications, test bench and VEB 
documents, electrical plans, etc. 
Testers' experience necessary for the 
investigation must cover all the 
equipment involved in the test. Part 
of the equipment is shown in figure 
1 . 

Hence, when complex faults occur, 
particularly those appearing during 
overall control tests, experts of 
various domains (EGSE, software, on- 
board equipment) have to conduct 
investigation sessions and search for 
the faulty equipment. These 

sessions, though necessary, require 
important time expense from different 
specialists. Moreover, testers 

sometimes spend a large amount of 


time dealing with problems that could 
be easily solved by experts. Thus, 
an assistance tool for the 
identification of faulty equipment 
will improve the efficiency of 
diagnosis and the overall 
productivity of test activities. 

2.2.2 The Existing Management of 
Incidents 

All the incidents are written down on 
nonconformance reports . These 
reports can be, if necessary, 
consulted to find out whether the 
present incident already occurred in 
the past . They are attached to 
documents describing the diagnosis 
approach that was taken in the search 
of the cause of incidents. They can 
help testers to elaborate an 
appropriate diagnosis approach for a 
current inc ident . 

2 . 3 THE NEEDS 

2.3.1. An assistance for the 
Evaluation of the Context 

When confronted with an incident, 
integration responsibles have to take 
into account the global context in 
which the incident appears. This is 
a critical phase since from this 
context evaluation, testers will take 
actions such as complementary tests 
to determine the cause of anomalies. 
A good evaluation of context will 
allow carrying out appropriate 
actions, the impact of which will not 
disrupt the diagnosis process and the 
incident context. 

2.3.2 A Reduction in the Time 
Required for Diagnosis 

When an anomaly occurs during the 
test phase, the rapidity of its 
resolution will improve the global 
productivity of test activities. 

This is particularly true when the 
VEB is under tests with special 
conditions such as vibrations and 
thermal constraints. Indeed, in this 
context, the faster the correct 
diagnosis, the better it is, since 
that prevents exposing the VEB too 
long under environmental conditions 
that are far harder than real ones. 

2.3.3 A Search for Appropriate 
Information to Make a Reliable 
Diagnosis 
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The diagnosis must be reliable. The 
performance of a reliable diagnosis 
depends on the identification of 
correct information. Hence , it is 
necessary, when an anomaly appears, 
to look for useful complementary 
information. That information is 
linked to the context of the anomaly 
appearance . 

Another consideration is that several 
types of anomalies can have similar 
symptoms on the test results. Hence, 
complementary tests will permit 
obtaining more information. The 
diagnosis approach must follow a 
strategy which ensures an 
optimization of actions to be 
performed and a maximum of 
reliability and safety. 

2.3.4 Adaptation of Old Incident 
Solutions to Present Anomalies 

The rapidity, the efficiency, and the 
analysis approach are often achieved 
owing to the experience of testers. 
This experience relies on adapting 
diagnosis process from old cases to 
present problems. Thus, old cases 
can be of great help in understanding 
the present context and elaboration 
of the diagnosis approach. 

3 THE RESPONSE 

As a solution, we consider the 
opportunity of a knowledge based 
system intended to assist testers in 
diagnosis. Given an incident, the 
system will assist users in making 
good hypotheses and in having an 
appropriate process to run 
complementary test actions to 
validate the hypothesis. 



Figure 2: The integration of the expert system in the test environment 


To manage the acceptability and the 
introduction of AI techniques and 
culture in this operational 
environment, we benefit from an 
expert completely involved in the 
development of the expert system 
itself. This aspect will also serve 


our long term goal, which will be 
detailed in the next paragraphs. 

The main originality of our approach 
is to consider the solution and the 
knowledge based system as a 
cooperative tool that should help the 
operator. This point of view differs 
from the usual ways of considering AI 
applications, which often neglect the 
user . 

This focus on the user induces 
implicit yet significant changes in 
the status of the system to be 
developed: 

building an expert 
system results in 
putting expertise at the 
user's disposal through 
an artifact, 

the design of the 
system not only focuses 
on the expertise itself, 
but also on the way the 
expertise its 
communicated and made 
available to nonexperts, 

- the knowledge based 
system (KBS) becomes 
much more dependent on 
its use context and on 
the technical 
environment it will be 
integrated in. 

A KBS will not meet these 
requirements unless it behaves like 
an intelligent team-mate, a 
cooperative tool that contributes to 
the improvement of the user's task 


achievement with 

competencies . 

its 

own 

Considering a KBS 

from 

this 


perspective has several consequences 
on the way it must be designed. We 
intend to take such constraints into 
account in the life cycle we follow 
to develop AI applications. Our 
methodology combines results from 
human factors, knowledge engineering 
and modelling to ensure the system 
acceptability by the end users* 

— The work organization in which the 
system will be settled is to be taken 
into account as soon and as closely 
as possible. This refers to the work 
organization, the people concerned 
with the project, existing and future 
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tools , etc* The purpose is to manage 
a good integration of the system 
within this context* The previous 
paragraphs describe the AIT/AIV 
context and work activities* 

--Building a cooperative system 
requires a strong reference to the 
user's abilities and know-how in 
performing the test, both with and 
without the help of a system* The 
user's task analysis provides 
information about the user's needs 
and the expected functionalities and 
roles of the target system. It helps 
specify the kinds of cooperation 
expected. AIT/AIV operators expect 
the diagnosis expert system to save 
time in localizing causes of defaults 
and to explain its diagnosis process. 

— The acquisition of the knowledge 
required by such a system should not 
be restricted to the early stages of 
the system life-cycle, but it should 
be continued to enrich the system as 
long as it remains in use. We 
promote a modelling approach, where 
knowledge acquisition consists of 
building an expertise model 
independent of the symbolic 
representation in the knowledge base. 
This model serves as a medium of 
communicaiton between the expert, the 
knowledge engineer and, later, the 
maintenance engineer. It provides a 
frame that guides the acquisition and 
modelling of new knowledge. Such a 
model is to be translated in order to 
obtain the target system. The 
representation primitives should help 
design a cooperative system, that is 
to say, they should make it possible 
to explicate how the solving process 
can be adapted, according to 
strategies or context dependent 
constraints . 

- Validation of a KBS results from 
much more than the knowledge base 
qualification. The life cycle 
includes a step-by-step validation by 
users and experts . We consider the 
system as valid only after three 
kinds of properties have been 
checked: (i) it performs corrrectly 
the task it is intended to, (ii) the 
user understands what the system does 
(there is a "cognitive compatibility" 
between the users and the system 
sovling processes), and (iii) the 
system fits in its use environment 
(it is integrated with existing 
systems, practices and tools). 


In order to ensure the system 
usability, an experiment has been 
carried out with expert and non- 
expert operators. The language they 
use and the level of abstraction at 
which they solve a problem have been 
compared. The differences stressed 
will be taken into account in order 
to adapt the system interface and the 
kind of explanations it provides. 


3.1 THE SHORT TERM GOAL 

The knowledge contained in the expert 
system will allow dealing with the 
more usual problems encountered 
during overall control tests. 
Diagnosis during this particular type 
of test is difficult since all the 
equipment of the VEB is 
simultaneously functioning . Thus , 
when an anomaly appears, a global 
knowledge of the VEB is necessary to 
decide on the appropriate approahc. 
In agreement with the expert, we 
decided that the system will mainly 
consider the cause of anomalies as 
unique . 

At the present time, we are 
developing the prototype. It is 
planned to be delivered to testers in 
March, 1993. Having the system at 
hand will allow testers to suggest 
some modification or add-ons about 
the functionalities of the system. 
Presently there are suggestion from 
testers to implement explanation 
modules in the system. This will 
enable the system to justify and 
explain the deduction of its 
hypothesis and its diagnosis process. 

In the same way, the knowledge stored 
in the system will be available for 
testers to use and to make 
suggestions for its enrichment. 

3.2 The Long-Term Objective 

Our final objective is to make VEB 
test knowledge available to all 
testers. The knowledge stored in the 
expert system will then be enriched 
by different experts of different 
equipment of the VEB. In effect, 
initially the expertise stored in our 
system only concerns that of an 
expert in VEB tests. Then, as the 
system is used and AI techniques and 
culture is better understood by end 
users, we will better identify which 
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kind of knowledge from experts of 
specific VEB equipment can be added* 
Moreover, these experts will feel 
much more involved in the system 
design at that time. 

Figure 3 illustrates our approach. 


Figure 3: The expertise domain covered by the system in short term and long 
term p * rsp.e c lives 

Presently, experts of different 
domains in integration plan to 
evaluate the expertise of the system 
at the end of this year. Thus, it 
will be the first session where there 
will be a discussion on the quality 
of the system knowledge and also 
proposals to enrich it. 

Thus, by means of the system, we plan 
to make the knowledge as living as 
possible in the growth both of 
quality and quantity. And as the 
knowledge grows, the functionality of 
the system will grow as well. The 
results may be developments of 
different applications. Indeed, as 
we know better the context of test 
integration environment, we will have 
a deeper insight as to what can be 
done to still improve test activities 
in quality and productivity. 

To conclude, we aim at capitalizing 
the corporate memory of the test 
environment. This task implies 
gradual achievements which result in 
the development of advanced 
information processing systems such 
as expert systems. The making of 
these systems in turn will encourage 
people in test environments to 
improve and enrich the corporate 
knowledge in the Ariane4 test 
context . 

4 THE APPROACH 

To achieve the short-term goal we are 
carrying out the knowledge 
acquisition, the definition and 
realization of the system 
architecture and the definition of 
the man/machine cooperative model. 

The first two phases are more complex 


to achieve than by simply operating 
in the context of realizing a simple 
knowledge based system. Indeed, we 
have to lay clues for the long term 
goal. The last phase is useful for 
us to take into account the different 
constraints that are applied in test 
environments and, by this, to study 
the behavior of testers in various 
situations and contexts. This will 
help us to design well-fitted systems 
to end-users needs. 

4 . 1 Knowledge Acquisition 

As mentioned earlier, we stress the 
interest of knowledge modelling for 
knowledge acquisition. The model 
facilitates the understanding of the 
knowledge stored in the system and of 
its behavior when performing a task. 
It makes explicit the way the system 
will solve a problem, adapt its 
behavior according to the current 
goal and context, etc. The 
conceptual model can be considered a 
detailed specification of the 
knowledge base, independently of how 
it will be implemented. 

Such a model is used, of course, to 
acquire knowledge from the expert and 
to build up the system, but also to 
maintain it, to generate better 
explanations, etc. Even though 
making it explicit takes time, it 
turns the famous "knowledge 
acquisition bottle-neck" into a 
succession of modelling activities 
much more guided and efficient than 
rapid prototyping. 

In this project, knowledge 
acquisition is carried out following 
the MACAO methodology and using the 
associated tool. This method 
promotes a bottom-up modelling 
process from the analysis of cases 
solved by the expert. Model-based 
knowledge acquisition can be 
decomposed in four major stages: 

- data-driven knowledge acquisition 
where information (rough data) is 
drawn from the various knowledge 
sources (expert's activity, 
documents, etc.) without any 
predefined idea about the expertise, 

- abstraction of a schema of the 
conceptual model: the tasks 
performed by the expert are 
characterized as well as the methods 
he uses and his strategies; also his 
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representation of the domain entities 
is associated to a kind of model 
structure,. 

- building of the full conceptual 
models the schema of the model is 
filled with all the required 
application knowledge until the model 
is complete; the schema may be 
consequently refined, 

- implementation of the conceptual 
model as the target system knowledge 
base. 

Figure 4.1. shows the different 
stages in knowledge acquisition and 
modelling. 



Figure 4.1.: Stages in knowledge acquisition and modelling 


With MACAO, several techniques are 
suggested in order to carry out each 
stage. A software helps build up the 
model: it proposes knowledge 

browsers and editors, structures for 
the model formalization. The 

conceptual model consists of two 
components: a domain model which 

gathers static knowledge about the 
expertise domain (concepts and their 
relations); a problem solving model 
that represents the task 
decomposition describing how a 
problem can be solved. Each model is 
represented with a specific language: 
semantic networks for the domain 
model, a graph of schemas for the 
problem solving model. Both are 
shown through graphs editors. 

The techniques promoted by MACAO are 
derived from human factors 
psychology or ergonomics, as well as 
knowledge acquisition. For instance, 
for data-driven knowledge 
acquisition, one of the techniques 
proposed is problem simulations, 
followed by focused interviews 
bearing on explanation of the 
simulations. Repertory grids are 
used to identify classes of problems. 
The problems solved by the expert 


form a set of cases that are compared 
in order to abstract the 
characteristics of the expertise and 
the schema of the conceptual model. 

The graph in figure 4,2. represents 
the schema of the conceptual model 
obtained with our application. The 
application is solved with a method 
close to systematic diagnosis, and 
exploits a functional model of the 
V.E.B. 



Figure 4.2. : The first stages in the diagnosis process modelled in the problem 

solving framework 


The use of MACAO on this application 
facilitates the two stages scheduled 
in the project because the model can 
be increased step by step. Moreover, 
it helps understand better the 
expertise when the system is 
extended. 

The schema of the conceptual model 
plays the role of a frame that guides 
implementation choices as well. 
Depending on the expert's 
availability, the system can be 
developed with more or less 
expertise. The least amount of 
knowledge required is the schema of 
the conceptual model. It can be used 
to decide whether the system can be 
built with a case-based or a model- 
based reasoning approach. It 
provides information on the kind of 
domain model used for model-based 
reasoning for instance. 

4.2 THE SYSTEM ARCHITECTURE 

We define the architecture of the 
diagnosis expert system as a hybrid 
one: it relies on rule based, case 
based and model based reasoning ( see 
Figure no. 4.3) . 
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Figure 4.3 The distribution of the three 
model competence 

Our goal is to combine AI techniques 
that can propose an efficient model 
of an expert ' s problem solving 
process. We assume suitable to 
combine Buie Based Reasoning, Model 
Based Reasoning (MBR) and Case Based 
Reasoning (CBR) techniques. Given an 
incident, the system will first rely 
on rules. If it doesn't succeed, CBR 
will be triggered to look for similar 
old cases. This can shortcut the 
model based diagnosis. Otherwise, 
the MBR must be triggered on the 
functional and structural model of 
the VEB. It can then assist the user 
or resolve the problem if its 
knowledge is strong enough. 

4.2.1 CBR as a Component of a Hybrid 
Architecture 

We decided to adopt case based 
reasoning techniques for two reasons: 
the expert refers to previous cases 
to solve new problems and many 
occurring incidents have already been 
encountered. Thus, when an incident 
occurs, the system will search for 
similar old cases to adapt the 
diagnosis approach to the present 
case. Explanation facilities 

concerning system reasoning will 
partly rely on the Case Based 
Reasoning architecture. 


Thus/ to ensure the modification and 
enrichment of our anomaly cases, we 
have to realize a global model of all 
the systems involved in the test 
(sub-systems in test, interface unit, 
test bench. .. ) and their connect ions 
with each other. This modelling 
corresponds to the view the expert 
has on the test environment and is, 
in fact, constituted with different 
levels of models. The following 
drawing (figure 5) illustrates a high 
level model concerning a Unit Under 
Test. (Lower level models correspond 
to more details for each equipment 
represented in the high level model). 
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Figure n°5 the integration respansibles have a global knowledge 
on the test environment. This global knowledge includes different levels of 
models they have on the test domain. Here we have a high level model 
concerning a Unit Under Test 



In addition to the description of the 
anomaly, we have to define all the 
concepts associated to the contexts 
in which the anomalies occur, such as 
symptoms, anomaly causes, and test 
context. Examples are: message- 
coming-from-the-test-bench, single- 
message, and sub-system-A-in-f ault . 

4.2.3 Case Organization in Ariane4 


4.2.2. CBR and the Domain Model 

The integration responsible has an 
overall view of his test environment. 
Thus he has a general knowledge of 
the system he has to test and of the 
test bench he uses. When an anomaly 
occurs, he has to find out the cause 
of this anomaly and to detect from 
which equipment it comes. In 
general, his diagnosis process ends 
when one equipment of the system in 
test is identified as guilty. Indeed, 


In Ariane4, we organize cases of 
anomalies in a two-level hierarchy: 

At the higher level, we have a set of 
super cases that gather subtypes of 
cases. A super case is characterized 
by common features of all the cases 
that belong to it. Of course, cases 
under super cases can have additional 
features just like subclasses and 
classes in object oriented 
programming paradigms. At the lower 
level, we have cases with their own 
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specific features • 

Given an incident , the system will 
search if there exists a super case 
with features that correspond with 
that of the incident. If this super 
case exists, then the system will go 
through the organization under this 
super case to localize potential 
similar old cases. Globally we can 
say that the super cases regroup 
information related to external 
symptoms that occur and the case 
organization under the super cases 
corresponds to the diagnosis 
approach . 

4.2,4 The System Architecture and 
the Long Term Objective 

In defining the architecture, we are 
particularly focusing on the 
possibility for the system to have 
its knowledge enriched and 
maintainable. Each time we have new 
knowledge to integrate in the system, 
we have to study its significance and 
impact. In effect, we can integrate 
this knowledge as new cases of 
anomalies (by using the Case Based 
Reasoning architecture), as new items 
of modelization (by using the Model 
Based Reasoning architecture) and as 
new heuristics (by translating them 
first at the level of the expert 
system conceptual model and then by 
coding them in the rule based 
architecture) . 

4 . 3 COOPERATIVE MODEL 

To adapt better the system to users' 
cognitive and physical skills, the 
man-system cooperation has to be 
precisely defined* The cooperative 
process, in our approach, is 
organized in a three layer model: 

the nucleus is a theoretical 
cooperative model, 

- the theoretical model is shaped by 
operational environment constraints, 

- the users behavioral model defines 
the cognitive compatibility between 
system and users. 

As a project parallel to that of 
corporate memory, we are building a 
cooperative model responding to the 
three above criteria. A system with 
such a cooperative model is capable 
of adapting its dialogue with the 


levels of users. Thus, for instance, 
the information (results, 
explanation, and reasoning) will be 
presented according to the testers' 
level of competence . 

This cooperative, for its advanced 
concepts, will not be implemented in 
the knowledge based system. But 
realizing it allows us to have more 
insight in the definition of the 
interface and functionalities of our 
expert system. 

Indeed, the cooperative model allows 
us to take better into account 
constraints of the work environment, 
characteristics of the work 
organization and human factor aspects 
in the context of Ariane4 VEB AIT/AIV 
activities. 

5. CONCLUSION 

Introducing the expert system in the 
context of Ariane4 VEB AIT/AIV 
activities will change the work 
organization. Indeed, when 
confronted with an incident, instead 
of only referring to documents and to 
human experts, testers can use the 
system as a source of knowledge and 
consider it as a tool of their own. 
Besides, they know that they can 
improve the performance of this tool 
by modifying and enriching its 
knowledge. Hence, in such a context, 
the work productivity is ensured as 
well as the technical level of the 
staff ~s kept high owing to the 
introduction of such a system. 

The approach we adopt in the context 
of Ariane4 to capitalize the 
corporate memory can be adapted in 
the context of satellite integration 
or in other work environment. At 
each environment, our approach will 
allow us to identify and capitalize 
the know-how and the experience and 
then to translate them in terms of 
advanced information systems. 

With the rise of information 
technology, one can feel overwhelmed 
in finding solutions to a problem 
encountered in his work environment. 
The approach we propose allow to 
master the solution by having a 
global understanding of the problem 
the parameters of which range from 
human factors to work domain. Hence, 
this enables us to have more insight 
as to choices in technical solutions. 
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Moreover , we enable a smooth 
introduction of advance systems in 
work organization to have more impact 
on the productivity and quality of 
work., 
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